The complexity and prevalence of communications networks has been increasing rapidly. As the number of data-based applications has skyrocketed, data transfer has expanded from simple computer-to-computer transfers to web browsing, video delivery, broadband data access, gaming, television, weather services, and the like. With an increasing number of applications depending upon data transfer, the ability to predict IP traffic has become increasingly more difficult. Accurate prediction of IP traffic flow and data management is helpful for maintaining and delivering quality services to customers. However, there are few, if any, accurate predictive models for network traffic.
In lieu of accurate modeling, several quality management approaches are sometimes used to address the issue of unpredictable network demand. One quality management approach includes time division multiplexing (TDM). In TDM, two or more signals are transferred as sub-channels in one communication channel, by taking sequential turns transmitting signals on one channel. The time domain is divided into several timeslots of fixed length, one for each sub-channel. Prior to initiating a TDM data session, a session service quality is evaluated and granted through the network administration. A TDM data session is established by a regular time-slot allocation through a negotiation process with the network. In general, the network reserves some time slots to keep these time slots open and available. As such, quality of service (QoS) for individual users may be maintained, but may result in network inflexibility and unused idle capacity. As such, many TDM systems result in some data sessions being delayed in the service queuing line waiting for access permission while some of the reserved TDM time slots remain idle.
Compared to TDM data access, best-effort transmission (BET) reflects a flexible data management at another policy extreme. With BET, all data sessions can access the network instantly. At times, the parties attempting to access the network will be successful, while sometimes the parties will be held and delayed. Some data sessions are not sensitive to delay, for example, email or file transfers. In such cases, interruptive delays can be tolerated and the file and/or email transfers can resume when the network resources are available. Some other applications are not as tolerant of interruptive delays. For example, in cases of real-time delivery of IP data, video, and the like, performance will be adversely affected by transmission delays. BET cannot guarantee a QoS delivery. These interruptive delays will show up on service records and/or can interrupt and/or stop various services.